Method and system for interoperable identity and interoperable credentials

ABSTRACT

Method, system, and programs for interoperable identity and interoperable credentials. In one example, an authentication request is received. The authentication request originated from an online user in connection with an application having a first LOA. The authentication request includes the online user&#39;s input. A digital identity is searched based on the online user&#39;s input. A GUID associated with the digital identity is obtained when the digital identity is found. One or more credentials that are bound to the GUID at the first LOA or a higher LOA are provided. A selection of at least one credential is received. Information of the selected credential that includes a credential verification service capable of verifying the selected credential is received. Verification of the selected credential of the online user based on the GUID is requested. A verification response is received. The online user is authenticated at the first LOA when the verification response indicates that the selected credential is successfully verified.

CROSS-REFERENCE TO RELATED APPLICATION

The present application claims priority to the U.S. Provisional PatentApplication No. 62/042,973, filed on Aug. 28, 2014, entitled “METHOD ANDSYSTEM FOR INTEROPERABLE IDENTITY AND INTEROPERABLE CREDENTIALS,” whichis incorporated herein by reference in its entirety.

BACKGROUND

1. Technical Field

The present teaching relates to methods, systems and programming foridentity management. Particularly, the present teaching is directed tomethods, systems, and programming for computing measures to be used toprovide interoperable identity among various service providers and toprovide interoperable credentials.

2. Discussion of Technical Background

In the healthcare environment, online identity solutions that providesecure and interoperable identities are essential. Identity managementtechnology provides management of identities in the digital world. Inorder to manage the growing number of online identities of a person oran entity, identity federation technology is developed so that differentweb-sites can reuse a single online identity.

A federated identity service provider provides user management andauthentication services to a plurality of systems of different entitiesor web-sites, which are also called relying parties. A relying party,typically an application service provider, delegates to the identityservice provider to authenticate an end user who is requesting access tothe application service provider. As such, the relying party needs totrust the identity service provider to have correctly authenticated therequesting end user's identity.

An authentication process typically includes the process of verifying acredential the end user presents. In an electronic information system, adigital credential is issued to a legitimate user and will be usedsubsequently to authenticate the legitimate user. A classic example of adigital credential is a secret password, a passphrase or a pin number.Now, there is an increasing number of uses of other forms of digitalcredentials, such as, for example, biometrics (finger prints, voicerecognition, retinal scans etc.), hard tokens, security devices, publickey certificates, etc.

To objectively assess the quality of an authentication result, NISTdocument 800-63-1 defines the a number of levels of assurance (LOAs)which describe the degree to which a relying party can be assured thatthe credential being presented actually represents the entity named init and that it is the represented entity who is actually interactingwith the relying party.

LOAs are based on two factors: (1) how much can a digital credential betrusted to actually belong to a person. This factor is generally handledby identity proofing; (2) how much the digital credential can be trustedto be a proxy for the entity named in it and not someone else, i.e.identity binding. This factor is directly related to the trustworthinessof the credential technology, the processes by which the digitalcredential is secured to a token, the trustworthiness of the system thatmanages the credential and token, and the system available to validatethe credential or the token.

SUMMARY

The teachings disclosed herein relate to methods, systems, andprogramming for providing identity management and authenticationservices. More particularly, the present teaching relates to methods,systems, and programming to provide interoperable identity services forvarious services providers and to enable interoperability of credentialsduring the authentication process.

In one example, a method, implemented on at least one computing devicehaving at least one processor, storage, and a communication platformconnected to a network for managing identity information of a person ispresented. The person's name is received after the identity of theperson has been proved at an identity proofing (IDP) level of assurance(LOA). Information related to a credential that is associated with theperson is received. The credential can be verified by a credentialverification service at a LOA that is of the same or lower level thanthe IDP LOA. A chosen name of the person is obtained. A combination ofthe person's name and the chosen name uniquely identifies the person. Adigital identity is created based, at least in part, on the person'sname and the chosen name. A globally unique identifier (GUID) isgenerated. The GUID associates with the digital identity and binds tothe person. The GUID is bound with the credential. A record of theperson that includes at least the IDP LOA and information related to thecredential and the credential verification service is stored.Information is transmitted to the credential verification service thatthe person is to be authenticated via the GUID based on a real-time userinput associated with the credential.

In another example, a method, implemented on at least one computingdevice having at least one processor, storage, and a communicationplatform connected to a network for authenticating an online user ispresented. An authentication request is received. The authenticationrequest originated from the online user in connection with anapplication having a first level of assurance (LOA). The authenticationrequest includes the online user's input. A digital identity is searchedbased on the online user's input. A globally unique identifier (GUID)associated with the digital identity is obtained when the digitalidentity is found. One or more credentials that are bound to the GUID atthe first LOA or a higher LOA are provided. A selection of at least onecredential from the one or more credentials is received. Information ofthe selected at least one credential that includes a credentialverification service capable of verifying the selected at least onecredential is received. Verification of the selected at least onecredential of the online user based on the GUID is requested. Averification response is received. The online user is authenticated atthe first LOA when the verification response indicates that the selectedat least one credential is successfully verified.

In still another example, a method, implemented on at least onecomputing device having at least one processor, storage, and acommunication platform connected to a network for authenticating anonline user is presented. One or more credentials associated with aglobally unique identifier (GUID) corresponding to a person are stored.The GUID and a first level of assurance (LOA) associated with anapplication are received. At least one of the one or more credentials isdetermined. Each of the determined at least one credential is at thefirst LOA or a higher LOA. The determined at least one credential isprovided so that the online user who claims to be the person can beauthenticated based on a credential selected from the at least onecredential.

Other concepts relate to software for interoperable identities andinteroperable credentials. A software product, in accord with thisconcept, includes at least one non-transitory machine-readable mediumand information carried by the medium. The information carried by themedium may be executable program code data regarding parameters inassociation with a request or operational parameters, such asinformation related to a user, a request, or a social group, etc.

In one example, a non-transitory machine readable medium havinginformation recorded thereon for managing identity information of aperson is presented. The recorded information, when read by the machine,causes the machine to perform a series of processes. The person's nameis received after the identity of the person has been proved at anidentity proofing (IDP) level of assurance (LOA). Information related toa credential that is associated with the person is received. Thecredential can be verified by a credential verification service at a LOAthat is of the same or lower level than the IDP LOA. A chosen name ofthe person is obtained. A combination of the person's name and thechosen name uniquely identifies the person. A digital identity iscreated based, at least in part, on the person's name and the chosenname. A globally unique identifier (GUID) is generated. The GUIDassociates with the digital identity and binds to the person. The GUIDis bound with the credential. A record of the person that includes atleast the IDP LOA and information related to the credential and thecredential verification service is stored. Information is transmitted tothe credential verification service that the person is to beauthenticated via the GUID based on a real-time user input associatedwith the credential.

In another example, a non-transitory machine readable medium havinginformation recorded thereon for authenticating an online user ispresented. The recorded information, when read by the machine, causesthe machine to perform a series of processes. An authentication requestis received. The authentication request originated from the online userin connection with an application having a first level of assurance(LOA). The authentication request includes the online user's input. Adigital identity is searched based on the online user's input. Aglobally unique identifier (GUID) associated with the digital identityis obtained when the digital identity is found. One or more credentialsthat are bound to the GUID at the first LOA or a higher LOA areprovided. A selection of at least one credential from the one or morecredentials is received. Information of the selected at least onecredential that includes a credential verification service capable ofverifying the selected at least one credential is received. Verificationof the selected at least one credential of the online user based on theGUID is requested. A verification response is received. The online useris authenticated at the first LOA when the verification responseindicates that the selected at least one credential is successfullyverified.

In still another example, a non-transitory machine readable mediumhaving information recorded thereon for authenticating an online user ispresented. The recorded information, when read by the machine, causesthe machine to perform a series of processes. One or more credentialsassociated with a globally unique identifier (GUID) corresponding to aperson are stored. The GUID and a first level of assurance (LOA)associated with an application are received. At least one of the one ormore credentials is determined. Each of the determined at least onecredential is at the first LOA or a higher LOA. The determined at leastone credential is provided so that the online user who claims to be theperson can be authenticated based on a credential selected from the atleast one credential.

BRIEF DESCRIPTION OF THE DRAWINGS

The methods, systems and/or programming described herein are furtherdescribed in terms of exemplary embodiments. These exemplary embodimentsare described in detail with reference to the drawings. Theseembodiments are non-limiting exemplary embodiments, in which likereference numerals represent similar structures throughout the severalviews of the drawings, and wherein:

FIG. 1 is a high level depiction of an exemplary system configuration ofthe present teaching, according to an embodiment of the presentteaching;

FIG. 2-a shows an exemplary user interface for a LOA2 application inwhich an end user may login via a LOA2 credential through OneStopidentity center, according to an embodiment of the present teaching;

FIG. 2-b shows an exemplary user interface for a LOA3 application inwhich an end user may login via a LOA3 credential through OneStopidentity center, according to an embodiment of the present teaching;

FIG. 3 is a flowchart of an exemplary process in which OneStop identitycenter authenticates a user at a requested LOA, according to anembodiment of the present teaching;

FIG. 4 shows an exemplary system diagrams of OneStop identity center,according to an embodiment of the present teaching;

FIG. 5 shows a flowchart of an exemplary process in which OneStopidentity center authenticates the user at a particular LOA with reusablecredentials, according to an embodiment of the present teaching;

FIG. 6-a shows a conceptual view of an exemplary role of OneStopidentity center in managing a person's various online identities,according to an embodiment of the present teaching;

FIG. 6-b shows portions of data used in an exemplary attributemanagement feature of OneStop identity center, according to anembodiment of the present teaching;

FIG. 6-c shows exemplary system diagrams of OneStop identity center thatincludes the attribute sharing feature, according to an embodiment ofthe present teaching;

FIG. 6-d shows an exemplary user interface of OneStop identity centerwhere the user manages attribute sharing among various trustedapplications, according to an embodiment of the present teaching;

FIG. 7 shows exemplary user interface for an authenticated user of atrusted application to register with OneStop identity center, accordingto an embodiment of the present teaching;

FIG. 8 shows a flowchart of an exemplary process in which anauthenticated user of a trusted application shares the user's identityattributes in the trusted application with OneStop identity center inorder to register with OneStop identity center and become a OneStop useridentity center, according to an embodiment of the present teaching

FIG. 9 shows a flowchart of an exemplary process in which an OneStopidentity center user get registered to a new trusted application,according to an embodiment of the present teaching;

FIG. 10 depicts a general mobile device architecture on which thepresent teaching can be implemented; and

FIG. 11 depicts a general computer architecture on which the presentteaching can be implemented.

DETAILED DESCRIPTION

In the following detailed description, numerous specific details are setforth by way of examples in order to provide a thorough understanding ofthe relevant teachings. However, it should be apparent to those skilledin the art that the present teachings may be practiced without suchdetails. In other instances, well known methods, procedures, systems,components, and/or circuitry have been described at a relativelyhigh-level, without detail, in order to avoid unnecessarily obscuringaspects of the present teachings.

The present disclosure describes method, system, and programming aspectsof methods and systems for providing a centralized identity managementand authentication services to a plurality of trusted applications orservice providers. The objectives of the present teaching include, forexample, providing centralized management of identity information in atrusted frame work, using a portable, easy to use chosen name to createa unique identifier to universally identify a person, enablinginteroperable credentials and allowing individuals to reuse alreadyobtained credentials, protecting the privacy of personal information(identity attributes and other identity information) by separating itfrom the authentication process. For example, using anonymous digitalcredentials that do not contain personal information such as theperson's name, birth place, birth date, or biometric information such asa picture or a finger print.

Moreover, the method and system disclosed in the present teaching canprotect the privacy of personal information by providing a multi-stagelook up mechanism, so that there is no direct access to a person'sidentity information without successful authentication. The binding ofthe identity and the digital credential provides additional protectionto the identity information.

A credential manifests a person's relationship to an entity. Even thoughthe relationship is established first by verification of identityinformation—the identity proofing process. The established relationshipis embodied in an anonymous digital credential that no longer includesidentity information. As a result, authentication of an identity nolonger requires identity information. Rather, authentication becomes aseparate process to verify an anonymous digital credential. Further, thefrequency of the authentication process does not compromise privacy.

NIST document 800-63-1 defines four levels of assurances (LOAs), as wellas the protocols for and practices used for each level. In the presentteaching, the identity service provider is designed to comply with theseprotocols and practices in its use of LOAs both in the process ofidentity proofing, credential management and end user authentication.

The identity provider may be validated by a third party. The identityprovider may also belong to a trusted frame work that serves a communityof relying parties. In the present teaching, an identity service requestto the identity service provider includes both an identity assertion andthe level of assurance for the identity assertion. For example, as seenbelow, US federal government may establish a trust framework to ensuresecure transactions between a citizen and business online services.

1. Centralized Identity Management

An identity is a set of attributes related to an entity. The identity ofa human entity, such as a person, is recognized by one or manyattributes of the person, such as, for example, attributes that theperson have provided to various social entities, where by the socialentities may have, for example, recorded the person's attributes intheir information systems.

In one example, a person's identity may include physical attributes suchas height, weight, hair color, eye color, etc. These attributes may beused for a driver license issuing authority. These attributes may beaccessible through an application or web site of the driver licenseissuing authority.

In another example, the person's identity may include attributes such asdate of birth, gender, and place of birth. These attributes may, forexample, be recorded at the person's birth certificate and accessible bya computerized system or web site of the person's birth certificateissuing authority. These attributes may be referenced, for example, byUS Department of the State's information system when the person usesthese attributes to apply for a US passport.

With time, the person's identity grows since the person interacts withmore and more social entities through life and as a result acquires moreand more identity attributes with respect to each of the socialentities. With the prevalence of information technology, frequently, thesocial entities maintain the person's identity attributes and make themaccessible through a computerized system or web site. For example, theperson enters the education system and may acquire attributes such as astudent id from the college he is attending. The person may also acquirea student email account. Both the student id and the student emailaccount attributes are accessible through an application or web site ofthe person's college information system.

Similarly, when the person is employed, the person may acquire anemployee id attribute from the person's employer whereby the personwould be recognized by in the person's employer information system. Instill another example, the person may acquire attributes in hisprofessional fields and being recognized by specific professionalorganizations: a doctor may have a National Provider Identifier (NPInumber) attribute as issued by the Centers for Medicare and MedicaidServices (CMS); a lawyer may acquire an attribute of a state bar licensenumber for the state that he is licensed to practices law.

In another example, the person may interact with entities in thefinancial industry, such as banks, credit card companies, mortgagecompanies. The person acquires additional attributes such as bankaccount numbers, credit card numbers, and mortgage account numberswithin these entities.

Similarly, when the person interacts with service providers such as aphone service provider, the person may acquire a mobile phone number, ora land phone number attribute. When the person subscribes to cableservice, internet service, water, gas, electricity service, newspaperservice, the person may also have acquired attributes such as an accountnumber from each of these services.

Moreover, when the person interacts with various online serviceproviders; social media service providers, online shopping serviceproviders, communication service providers, data storage serviceproviders, and digital entertainment service providers, etc. The personmay acquire attributes such as, for example, a number of email accounts,twitter accounts, a Facebook accounts, an aliased account on an onlinechat forum, etc.

In still another example, the person may interact with entities in thehealth care industry, and acquires attributes from the interactinghealthcare entities. For example, the person may acquire a patient ID xfrom hospital A's system when, for example, the person went to hospitalA's emergency care facility after an accidental fall from the stairs.The person may acquire a different patient ID y from hospital B's systemwhen the person went to hospital B for cardiovascular care.

In summary, a person's identity, i.e., the various attributes thatrelate to the person are fragmented and distributed in a vast number ofcomputer systems of different social entities and services providers.

Problems exist for such distributed identity configuration. For example,some of these attributes are common among many entities; as a resultthese attributes are duplicated in multiple copies in multiple entities.For example, the “current address” attribute may be exist in manyentities, such as, for example, the person's bank, the person's creditcard company, the person's account in Amazon.com, the person's employer,the person's primary care doctor's practice, the person's record withthe DMV, the person's record with the state bar association, etc.

The repetitive nature of these attributes creates two problems. First,it is burdensome for a person to repeatedly provide this information toevery entity that requires it. Second, it becomes burdensome for theperson to update changes to such attributes, and manually update everycopy of the same attributes. For example, when the person moves to a newaddress, the new “current address” attribute need to be updated to allthe entities, such as the entities listed above.

The present teaching provides a solution to the above problems. Thepresent teaching enables the person to have centralized control over theperson's identity attributes and their uses in various entities as itprovides secure exchange of identity information among a wide group ofidentities while reducing risk. For example, the present teachingenables identity attributes be distributed to or shared among trustedentities so as to reduce duplicate copies of the same attributes indifferent entities. Having centralized control over decentralized datastorage provides efficiency without sacrificing data privacy.

2. Universal Identifier

As seen in the examples above, the person's identity is distributed inmultiple entities, with each entity maintaining a subset of the person'sidentity attributes, as well as some other information with respect tothe person. For example, the college the person attended may maintainthe person's identity attributes, such as student ID, student emailaccount, The University may also keep other information about theperson, such as, for example, the person's enrolling period, degreeearned, date of the degree earned, permanent address of record, etc.These other attributes may also be used to identify a student if thestudent id is being reused, for example, after 20 years.

In another example, at birth, the person builds a connection to hisbirth country's government by establishing a “legal name” identifier tothe government, for example, by applying for a birth certificate toprove this connection. The government may also record the otherattributes, such as the person's gender, date of birth, place of birth,parents' names, etc. When two person have the same legal name, theperson's other attributes may be used to distinguish them.

Within the universe of each entity, the person may be associated with anidentifier that uniquely identifies the person within that particularentity. For example, a social security number can be an identifier touniquely identifies the person for the US federal government; a driverlicense number can be an identifier to uniquely identity the person inthe person's residential state; a student id can be an identifier touniquely identify the person in the person's university; a bank accountnumber.

In still another example, a lawyer's state bar license number is aunique identifier to identity the lawyer in that state bar association.In still another example, a doctor's National Provider Number (NPInumber) is a unique identifier to identify the doctor in the healthcaresystem.

These identifier attributes are important personal identificationnumbers. However, these numbers are randomly generated before beingassigned to a person, and thus, are not easy to remember. These numbersmay be presented in the form of ID cards, such as a social securitycards, driver license, bar license cards, etc. However, managing theseextra ID cards or id numbers can be burdensome. It also causes securityproblems when such ID cards are lost or stolen.

The present teaching teaches a method for creating a consistentidentifier that can be used universally across all trusted entities,thus reducing the need to manage multiple identifiers. Morespecifically, the present teaching provides a Chosen Name identifier, aname that the person choses for himself/herself, a name that the personprefer to be called despite his real name.

The present teaching also enables secure exchange of user identityinformation between OneStop and the trusted entities under the user'sconsent. A trusted entity may require a specific set of identityattributes to map an OneStop identity to a user account of the trustedentity. For example, a personal healthcare record system (PHI) requires5 identity attributes to find a user's account: first name, last name,date of birth, gender and zip code. Upon user's consent as presented,for example, through an OneStop user interface, OneStop may share these5 attributes of the user with the PHI system, for example, in an OpenIDConnect ID token, along with the user's GUID in the OneStop system.

On the other hand, a user may apply for an OneStop account via a trustedapplication. In other words, the trusted application may act as anidentity proofing agent for OneStop.

For example, the person may consent to the PHI system to provide the 5identity attributes, such as first name, last name, date of birth,gender and zip code to OneStop, PHI system may also provide the LOAbased on its record of the user's identity proofing in the PHI system.In one embodiment of the present teaching, using the OpenID Connectprotocol (http://openid.net/connect/faq/), PHI system may serve asUserInfo endpoint for OneStop, so that OneStop may obtain the 5 neededattributes and the LOA level securely from the PHI system. The OpenIDConnect protocol include ID token, which include information about theauthenticated user. The UserInfo endpoint in the OpenID Connect protocolgets attributes about the user and translates the ID tokens.

3. Chosen Name: A Universal Personal Identifier

The present teaching may use a globally unique personal identifier forevery user of the OneStop identity center.

The identifier includes a person's first name, last name, a “&”, and theperson's chosen name. For example, Mr. James Chen decides that he wouldlike “Tiger” to be his chosen name; his identifier in OneStop would be“James Chen & Tiger.” In another example, suppose the fictitious figure,Mr. James Bond decides that he would like be called “007”, and use it ashis chosen name, his identifier in OneStop would be “James Bond & 007.”

A person's full name is the person's most significant social identifier,which includes at least a first name and a last name. However,traditionally neither the first name nor the last name is of theperson's own choice: the first name is chosen, normally, by the person'sparents; the last name is given, normally, by the person's family,either through birth or by marriage.

A chosen name is a name that the person prefers to be called despite hisreal name. The underlying philosophy of the chosen name is to provide aperson with an opportunity to choose a name for himself/herself, a namethat he can expresses himself as who he is, to reflect his preferenceand follow his own desire as how he/she should be recognized. Becausethe chosen name is centered on the person's own belief and created withhis own unique expression as to his/her identity. As such, the chosenname would be easy to remember and promotes user's frequent use.

Due to the human factors of the chosen name design as discussed above,it is the vision of the present teaching to have chosen name build itsweight with time, through frequent, consistent use, gaining universalacceptance in all aspects of the person's online interactions, and thusbecoming a part of the person's permanent identity.

As part of an online identity identifier, a chosen name may beimplemented using as a string. The string includes a sequence ofcharacters, and has an arbitrary but finite length. In one embodiment ofthe present teaching, the characters may include all alphabetic letters.In one embodiment of the present teaching, the characters may includeall characters in the Chinese language. Similarly, in other embodimentsof the present teaching, the set of valid characters may include allcharacters in the Japanese language, or Russian language, or Arabiclanguage, or any other written language

In another embodiment of the present teaching, the characters mayinclude all Arabic numerals. In another embodiment of the presentteaching, the characters may include both alphabetic letters and Arabicnumerals numbers.

To ensure the uniqueness of each globally universal identifier, andtolerate user input errors, the present teaching may use a thread holdvalue between the distances between any two global identifier strings.For example, the distance between an identifier “Jim Chen & Tiger” and“James Chen & Tiger” may be too short to distinguish each other. Commontypos, such as skipping a letter, reverse letters, double letters, mayalso create a string that has too a short distance to the correctspelling of the intended identifier.

In one embodiment of the present teaching, the Jaro-Winkler distance,measures the distance. The higher the Jaro-Winkler distance for twostrings is, the more similar the strings are. The Jaro-Winkler distancemetric is designed and best suited for short strings such as personnames. The score is normalized such that 0 equates to no similarity and1 is an exact match.

In another embodiment of the present teaching, the distance is measuredby the Levenshtein distance. The Levenshtein distance between twostrings is defined as the minimum number of edits needed to transformone string into the other, with the allowable edit operations beinginsertion, deletion, or substitution of a single character. Otherembodiments may apply different string distance algorithms, includingbut not limited to Euclidean Distance, Cosine/Sine similarity distance,Chapman Length, Soudex, Linear and no-linear clustering, as well asstring distance algorithms that are tailored to a particular language.

In still another embodiment, the distance is created by a machinelearning algorithm, where user input errors are captured and such errorsare used as feedback to correct the outcome of the distance algorithm.

4. Multi-Credential Authentication

In the present teaching, one purpose of a digital credential is to proveto a digital system that the presenter of the digital credential is thevery person/identity that is associated with the digital credential. Inother words, a digital credential serves as a proxy of theidentity/person to the digital system. The process to authenticate anidentity/person to a digital system becomes the verification of theproxy, i.e., the digital credential. As such, an identity can beasserted digitally via verification of the digital credential,

Examples of a digital credential may include something that the personcan remember, such as a password. A digital credential may also includesomething that the person carries, such as his mobile phone, a smartcard, a hard token or a USB device. A digital credential may alsoinclude something that the person is, such as, for example, a person'sbiometrics: voice, finger prints, iris scans, etc.

A person may have established a number of digital credentials during theperson's interactions to various entities. For example, the person mayhave obtained a smart card from the person's employer, the person mayobtained a Symantec hard token as a doctor to electronically prescribecontrolled substances to patients, the person may acquire a RSA securitytoken from the hospital system that the person works for.

Using a digital credential makes it easy to use and secure. Because thecredential is secured to a token, the trustworthiness of the system thatmanages the credential and token, and the system available to validatethe credential.

Digital credentials are issued to a person and become attached to theperson. Presenting the correct digital credential as linked to theidentifier enables the information system to trust the current userbeing the legitimate user. In other words, an identity can be assertedby authentication of the digital credential.

In the present teaching, authentication may be a process toelectronically verify an assigned credential of an identity as means toaccept an identity assertion of that identity.

For the same security reasons, the person may have gone through athrough identity proof process before being issued the digitalcredential. The person is further burdened to manage an increasingnumber of such security devices, each for a particular entity, eventhough they serve the same purpose.

The present teaching allows reuse of the collection of the existingcredentials the person has acquired from various entities. The presentteaching also manages security and trust among these establishedcredentials so that they can be used in other entities, based onstandards as set forth in NIST document 800-63-1. The present teachingfurther enables compound credentials, where more than one credentialsare used together for increased security. The present teaching providessecurity because it does not expose links or look up mechanism foridentity attributes.

Motivated by this challenge, the teachings presented herein provide asystem or service that utilizes improved approaches to a centralizedidentity management system which manages the identity attributes thatare collected from various source entities.

FIG. 1 is a high level depiction of system configuration in which acentralized identity management system manages the identities and enduser authentications for a number of trusted entities, according to anembodiment of the present teaching. To provide a context, an example ofthe use of the system is described below. The end user 110 may desire toaccess a trusted application 130 to obtain contents or services asprovided by application service providers for the trusted application130.

In accordance with the present teaching, the OneStop identity serviceprovider 140 performs a 3 step process: (1) identity searching; (2)credential selection; and (3) credential verification. In step (1)Identity searching: the identity center 142 may first search for theidentity with identifiers provided by the end user. The identity center142 then determines whether the end user 110 has sufficient level ofassurance (LOA) with its identity proofing record, as indicated in theidentity database 144. The identity center 142 may provide additionalidentity proofing to the end user 110 if needed to reach the desiredLOA.

In step (2) credential selection: the identity center 142 may search forthe credentials options of the end user 110 via communicating with acredential exchange 146. The credential exchange 146 may generateavailable credential options that are at or above the desired LOAs bylooking up in the credential database 146. The credential database 146includes credential information that the end user 110 may have.

In response, the end user 110 may select one particular credential toauthenticate him/her. In step (3) credential verification: based on theselected credential, the credential exchange 146 selects thecorresponding credential service agent 150 to verify the selectedcredential by interacting the end user 110. Finally, upon successfulverification of a valid credential, the identity center 142 provides atimed digital identity token to the requesting trusted application 130for the end user 110.

In FIG. 1, the exemplary system 100 includes an end user 110, a network120, a number of trusted applications 130, including application 1130-a, application 2 130-b, . . . application n 130-c, an identitycenter 142, an identity database 144, a credential exchange 146, acredentials database 146, a number of credential service agents 150,including Authentify xFA 150-a, Symantec 150-b, RSA 150-c, Federal PKIBridge (for PIV card), Verizon, and other credential service agent150-d.

The network 120 can be a single network or a combination of differentnetworks. For example, a network can be a local area network (LAN), awide area network (WAN), a public network, a private network, aproprietary network, a Public Telephone Switched Network (PSTN), theInternet, a wireless network, a virtual network, or any combinationthereof. A network may also include various network access points, e.g.,wired or wireless access points such as base stations or Internetexchange points, through which a data source may connect to the networkin order to transmit information via the network.

The end user 110 may connect to the network via desktop connections(110-a), or connect to the network via wireless connections such asthrough a laptop (110-b), or a handheld device (110-c). The end user 110may have number of authentication tokens for the specific purpose ofauthenticating himself/herself to access online applications or performelectronic transactions. The end user 110 may carry a hard token 112-b,such as, for example a Symantec hard token that generates codes thosechanges with time. Then end user 110 may also have a USB token 112-a,such as, for example a RSA Secure ID token. The end user 110 may alsohave a smart card 112-c, such as, for example, an identification cardissued by the end user's employer.

The trusted application 130 includes a number of trusted applications ina trust framework. The trust framework may be established by contractsamong all member entities for each of the member applications 130, andthe OneStop identity Service provider 140. The trust framework may alsobe established via certain certification program, where each memberentity or each member applications are certified to be in compliancewith a common security protocol. For example, for health informationexchange purposes, member entities and applications may follow the LOApractices as defined in the NIST document 800-63-1. In another example,a trust framework may be established by the federal government, such as,U.S. Federal Identity, Credential, and Access Management (FICAM) TrustFramework Solutions (TFS) program(http://info.idmanagement.gov/2013/11/ficam-trust-framework-solutions-tfs.html).

The trusted application 130 may include different applications withinone organization. For example, a doctor may access an electronicprescription application, a medical history application, and a HIPAAcompliant secure email application, all within one hospital system wherethe doctor practices. The trusted application 130 many also includeapplications from different organizations. For example, a doctor mayaccess an electronic prescription application from an applicationprovided by a clinical network, the doctor may access a medical historyapplication from an application provided by a health informationexchange (HIE) network, and the doctor may access a HIPPA complaintsecure email application hosted by a communications service provider.

In another example, a patient end user 110 may access a firstapplication from hospital 1 to access his recent in-patient record. Thepatient may access a second application in hospital 2 to access hisrecord for an emergency care. The patient may access an application inlab 3 to access his recent X-ray. The patient may access a fourthapplication from his/her insurance company for a medical claim.

Traditionally, a trusted application 130 handles its own identityproofing process. For example, upon the end user's initial registrationto the trusted application 130, an end user 110 may be required toinput, such as via entering into a form, his name, address, emailaddress, phone number and other relevant information about the user.Upon receipt of the user information and verifying it successfully,(i.e., identity proofing of the end user 110), the application 130 mayenable the end user 110 to create an account. The user account may beaccessed by an identifier (e.g., a user name) and a digital credential(e.g., a password).

To access a trusted application 130, an end user 110 may need toregister with the application 130. The registration process may requirethe end user 110 to provide sufficient information about the end user110, for purpose of, for example, identity proofing the end user 110 atthe desired LOA level of the application 130, as defined in thestandards as set forth, for example, in NIST document 800-63-1. In oneexample, the application 130 may be a free newsletter application thatdelivers to the user news on selected topics. The newsletter applicationmay require a LOA1 level of identity proofing, where the end user 110only need to provide a unique identifier and a personal email address.

In another example, the application 130 provides online shoppingservices, and requires a LOA2 level of identity proofing. In this onlineshopping application, the end user 110 may need to additionally providehis bank account information, or his credit card information, forexample, via the registration interface of the online shoppingapplication. The end user 110's user account will be created only afterthe application 130, here the online shopping application, has verifiedand proved accurate of the person's bank account or the credit cardaccount information. In another example, the application 130 is anapplication for accessing to a restricted system that is subject to issubject to regulatory requirements (e.g. HIPAA, DEA rules, etc.).

For example, the application 130 may be an electronic prescriptionapplication for doctors to prescribe controlled substances (EPCSapplication), where the end user 110 (e.g., a doctor) is required topass at least a LOA3 of identity proofing before enabled to createaccount in the EPCS application. In one implementation of the EPCSapplication, the end user 110 is required to pass a vigorous identityproofing process through the hospital system, where the end user110/doctor is required to be present in person, to the registrationstaff of the hospital, showing two forms of government issued picture IDwhich shows the doctors legal name, nationality, address and date ofbirth. In another example of an EPCS application, the end user110/doctor is required to respond to a letter that is mailed to him/herat his/her primary address. In still another example, the end user110/doctor is required to answer, via a landline telephone from hishome, various questions to prove his/her identity.

In still another example, the application 130 is a credential issuingapplication where a user is issued a credential based on sufficientidentity proofing at a particular LOA level. For example, theapplication 130 may be a Symantec application, where the user is issueda hard token upon successful identity proofing, for example, at LOA2.The application 130 may be a RSA application, where a user is issued RSAsecurity token upon successful identity proofing, for example, at LOA2.

In still another example, the application 130 includes an OneStopapplication where an end user 110 may go through the identity proofingprocess through the identity proofing process of the OneStop identitycenter 142 and being issued a credential by the OneStop identity center142.

OneStop identity service provider 140 is an identity management systemthat provides identity services for the trusted applications 130.OneStop identity service provider 140 includes an identity center 142and an identity database 144. In some embodiments, the OneStop identityservice provider 140 may also include the credential exchange 146 andthe credentials database 148.

In one embodiment of the present teaching, the OneStop identity serviceprovider 140 may engage identity proof agent, such as, for example,Google, PayPal, Equifax, Facebook, Twitter, LinkedIn, Microsoft toconduct the identity proofing process.

In another embodiment of the present teaching, the OneStop identityservice provider may contact with other identity providers, such as, forexample, to initially create OneStop users based on records from the USdepartment of State, Department of Homeland Security, VeteransAdministration Office of Personnel Management, CAQH, MyGov (GeneralService Administration), various State Department of Motor Vehicles, orNotary Services.

The identity database 144 includes identity information for each OneStopuser, including various identity attributes, identity proofing record,and identity binding records.

In one embodiment of the present teaching, the identity database 144includes the OneStop Chosen Name Identifier, an internal Global UniqueID (GUID)—a unique code used internally that corresponds to the OneStopIdentifier. The identity database may also include the user's identityproofing record and its LOAs. The user's identity proofing recordindicates how, when, where, by whom the OneStop user was being identityproofed. For example, an OneStop user, as identified by Ryan Williams &Drew, was identity proofed by the OneStop system, by Experian, onNovember 2012. He has reached a LOA2. In another example, a second user,as identified by Ellen Smith & Willow, was identity proofed by the EPCSapplication, on May 2011, certified at LOA3.

In one embodiment of the present teaching, the identity database 144 mayalso include information about the credentials that bound to the OneStopuser. For example, the user Ellen Smith & Willow, who is a registereduser of the EPCS application (a trusted application), having an identityproofing record of LOA3, who is also bound to a Symantec hard token asissued from the EPCS application, which ensures LOA3 authentication. TheSymantec hard token is a digital credential that may be uniquelyidentified by, for example, a serial number of the hard token. In thisexample, the serial number will also be included in the identitydatabase 144, for example, as a credential attribute as associated withthe OneStop user Ellen Smith & Willow. Additionally, the credentialattribute may also include other information about the credential, forexample, the LOA3 assurance level, the URI for verify this credential,and other information needed to initiate the authentication service ofthis credential.

The identity database may include the serial number of the Symantec hardtoken, as well as its LOA3 credential strength in Ellen's record in theidentity database 144.

In another embodiment of the present teaching, the credentials database148 includes information about the credentials that are bound to theOneStop user. In this embodiment, the identity binding (associationbetween an identity and one or more credentials) is separate from theidentity proofing records.

In accordance with the embodiments described herein, the trustedapplication 130 can redirect to OneStop identity service provider 140 toauthenticate the end user 110 with its required overall LOAs.

Overall LOAs of the identity service, as defined by the NIST document800-63-1, is determined by the LOAs in 3 aspects: identity proofing,credential strength, and authentication process. The overall LOA is theleast LOAs achieved by the three. For example, to reach an overall LOA3,the identity service need to have LOA3 or above in identity proofing,using credentials with strength of LOA3 or above, and applyingauthentication process with LOA3 or above (which requires at least twofactor authentication).

Credential service agents 150 refer to a plurality of service providersoperable to, for example, issue credentials and provide credentialservices (e.g. verification of the credentials). For example, thecredential service agents 150 may include an Authentifiy xFA 150-a, aservice provider which provides two factor authentication based on auser's voice. In another example, the authentication service may beprovided by Symantec 150-b where a hard token credential can beauthenticated. In another example, the identity center 142 may requestRSA Auth Manager 150-c to authenticate a hard token from RSA. Similarly,the identity center 142 may request other credential service provider150-d to authenticate another particular type of credential.

FIG. 2-a shows exemplary user interface for a LOA2 application in whichan end user may login via a LOA2 credential through OneStop, accordingto an embodiment of the present teaching. In this example, an exemplarysubject application (ABC Healthcare Application) requires LOA2 assurancelevel for its authentication process. An existing user of the ABCapplication may login normally through its conventional user interface,such as, for example, the user interface 210. In other examples of thepresent teaching, the user interface 210 may include any other login orauthentication interfaces that the subject application provides.

In this example as shown in the user interface 210 of FIG. 2-a, the useris required enter his/her User Name, which is specific to the ABCapplication. The user is also required to enter a correct password thatwas specifically set up for the ABC application. With the growingnumbers of web sites/applications that the user accesses, so do thenumber of authentication details, such as, username/password pairs, thatthe user is required to remember, or to manage. This can be quiteburdensome.

As a convenient alternative, the user may login to a subject applicationwith a consistent way through OneStop. In one example, the subjectapplication, such as, for example, the ABC application, provides a userinterface 220 where the user may, for example, be authenticated usingthe OneStop service. In contrast to using a particular user name that isspecific to the subject application, the user may use an unvarying,universal name through OneStop (a Globally Unique OneStop Name, GUON),no matter what subject application is.

The user's universal name, GUON, includes the user's first name, lastname and chosen name. As discussed earlier, OneStop ensures that theuser's universal name (GUON) is the user's true names that have beensufficiently verified and identity proofed, at least, at the requiredLOA level. In this example, the user interface 220 provides user inputfield First Name 232, Last Name 234, and Chosen Name 236 for user toinput its first name, last name and chosen name respectively. In anotherembodiment, the user interface 220 may include one text field whichaccepts the complete string of user's universal name GUON. In stillanother embodiment, the user interface 220 may provide masked charactersfeature for inputting the user universal name text field.

Further, in contrast to using a conventional password, or a particularcredential that is tired to the subject application, the user mayauthenticate himself/herself with any qualifying credential (acredential that is at the desired LOA level or above). For example, theuser interface 220 includes a credential list 242. The credential list242 may include, for example, a list of credentials at the LOA2 or abovethat OneStop currently is operable to handle. In another embodiment ofthe present teaching, the credential list includes a list of credentialsthat are tailored to the current user and include credentials that thecurrent user has acquired. In this embodiment, the credential list 242may be presented to the user after the user has correctly entered itsGUON via to the user interface 220.

In the example as shown in FIG. 2-a, the credential list 242 mayinclude, for example, a Symantec credential 242-a, such as a hard tokenthat display a changing pass code. The Symantec credential 242-a may,for example, have been issued by the OneStop, can be used forauthentication at LOA3. The credential list 242 may also include an xFAcredential 242-b with authentication valued at LOA3. In this example,the user may, for example, have registered with the xFA credentialservice provider, installed an xFA mobile application on the user'ssmart phone, and thus enabled to be authenticated by the xFA credentialprovider based on the user's voice print.

The credential list 242 may include for example, an Ezio Secure Card242-c that the user may have acquired, for example, from Amazon.com. TheEzio Secure Card 242-c also provides a changing pass code in its userinterface, and may have been issued, for example, at LOA2. Thecredential list 242 may include a credential 242-d, for example at LOA2,where the user can be verified by a code in a text message that will besent from PayPal to the user's mobile phone (also called PayPal mobilephone security key).

The credential list 242 may also include a RSA secure ID 242-e that isissued from Superscript, with LOA3. The RSA secure ID 242-e may be, forexample, a hardware device that displays a changing pass code that useris required to present during the RSA secure ID verification process.The credential list 242 may also include a credential 242-f that theuser has acquired for two factor authentication with Microsoft. Thecredential 242-f may be, for example, qualified at LOA2 and allowsMicrosoft to send the user a code in an email, where user logs into theaccount for the first time on a PC or other device.

The user interface 220 may also include a component 244. The component244 may be a button, or a link, or equivalent. Activation of thecomponent 244 may, for example, initiate a process where the currentuser may add additional new credentials to the OneStop service provider.

FIG. 2-b shows exemplary user interface for a LOA3 application in whichan end user may login via a LOA3 credential through OneStop, accordingto an embodiment of the present teaching. Similar to FIG. 2-a, thepresent teaching enables user to authenticate through a universal LOA3authentication process through OneStop. Again, the user uses the user'sGlobally Unique OneStop Name (GUON) regardless what subject applicationthe user is trying to access. Additionally, the user may authenticatehimself/herself with any qualifying credential (a credential that is atthe desired LOA3 level or above) that the user may have acquired.

In the example as shown in FIG. 2-b, a user interface 230 includes acredential list 252 at LOA3 that includes for example, a Symantec hardtoken 252-a, as acquired via OneStop, a XFA credential 252-b, and a RSASecure ID 252-c, as acquired via SureScript.

The user interface 230 may also include, for example, the component 244where the user may provide additional credentials at LOA3 or above tothe OneStop system.

FIG. 3 is a flowchart of an exemplary process in which OneStopauthenticate a user at a requested LOA, according to an embodiment ofthe present teaching. At step 310, OneStop receives an identityassertion and required LOA from a trusted application. The identityassertion may include, for example, the user's GUON, a string thatincludes user's first name, last name, “&” and chosen name. At step 320,OneStop searches in the identity database 144, for an OneStop identifierthat matches with the received GUON. At step 330, if an identity recordis found in the identity database 144, for example, with a matchingGUON, OneStop continues to check the identity proofing record for thefound identity.

Suppose, the found identity does not have a sufficient level of LOA asindicated in its identity proofing records, OneStop may, for example,redirect the user to start the process for additional identity proofingat step 340. In one example, the user is directed to an Experianwebsite, where additional identity proofing may be performed byrequiring the user to answer a number of questions that are generatedbased on the user's financial record with Experian.

Upon successful completion of the additional identity proofing at step350, OneStop may, for example, update the identity's identity proofingrecord, for example, with an elevated LOA, and/or with any otheradditional identity proofing details at step 360. If the user fails atadditional identity proofing at step 350, OneStop may, for example, denythe user's identify assertion at step 395, for example, by respondingwith an authentication failure code to the requesting application.

If the found identity has an identity proofing record that indicatesthat the IDP level is, for example, at the requested LOA or above, atstep 330, OneStop may continue to find qualifying credentials that arebound to this identity at step 370. In one embodiment of the presentteaching, the qualifying credentials for the identity are stored in theidentity database 144, as shown in FIG. 1. In another embodiment of thepresent teaching, as discussed in more detail below in FIG. 4, thequalifying credentials that are bound to the identity is stored by aseparate credential database 148 and managed by the credential exchange146.

In one embodiment of the present teaching, the user may select aparticular credential to authenticate the user. In another embodiment ofthe present teaching, OneStop selects a “master” credential at therequested LOA. In another embodiment of the present teaching, OneStopenables the user to select from a list of available credentials.

In one embodiment of the present teaching, OneStop may initiate theprocess to verify the selected credential at 380. For example, OneStopmay redirect the user to the credential verification service provider asrelated to the selected credential.

If the selected credential is verified successfully at step 390, OneStopmay, for example, provide a positive authentication response withrespect to the user to the trusted application at step 399. In oneembodiment of the present teaching, OneStop adopts the OpenID Connectprotocol, and provide an ID token for the user to the trustedapplication. In another embodiment of the present teaching, OneStop mayprovide a SAML token with respect to the user to the trustedapplication. In still another embodiment of the present teaching,OneStop may provide a signed digital identity with respect to the userto the trusted application.

If, however, verification of the selected credential fails at step 390,OneStop may, for example, return an authentication failure response atstep 395.

FIG. 4 shows exemplary system diagrams of OneStop with a standalonecredential binding system, according to an embodiment of the presentteaching. Having a standalone credential binding system provides strongprivacy because it creates a separation between a person's identityinformation and the person's credentials, i.e., information needed toprove the person's identity. In other words, the authentication processis separate from the identity information. In this embodiment, the linkbetween the person and the person's identity is managed by an internalID (GUID) of OneStop, which cannot be used nor understood by any otherentity or system.

In this embodiment of the present teaching, the OneStop identity center142 may manage the identity proofing process during the registrationprocess of a user. The OneStop identity center 142 may engage varioustrusted identity proofing services or agents to register a user.

The credential exchange 146 in this embodiment provides no link to theperson, or the person's identity information/attributes. Suchimplementation separates identity proofing process from the identitybinding process.

In this embodiment of the present teaching, the credential managementand services may be handled by an independent system that comprises acredential exchange 146, credentials database 148, and a number ofcredential service agents 150.

Credentials database 148 stores credential records for all OneStopusers, as well as information relate to the verification of thecredential. For example, an OneStop user may have a Symantec hard tokenthat was issued to him/her as a LOA2 credential. The credential database148 may store, for example, a credential record for the OneStop userthat includes, for example, the serial number of the Symantec hardtoken, its classification as a LOA2, its issuing entity OneStop, the URLthat relate to the verification process of the hard token, the validperiod of the hard token, the option to renew, the permission to replacewith a new hard token, and any other relevant information. The OneStopuser may be referenced in the credential database 148 by, for example, aGUID of the OneStop user.

A credential record in the credential database 148 is configured tostore various types of credentials of different LOAs. For example, acredential record may store a LOA2 strong or encrypted password, acredential record may store an identifier to a LOA3 or LOA4 smart card,a credential record may store a mobile phone id. A credential record mayalso operable to store PKI keys, digital certificates or any other typeof digital credentials.

The credential exchange 146 may also manage credential binding, where anOneStop user's GUID become associated with a credential record. Thecredential exchange 146 also manages credentials for OneStop users andinitiates credential verification process with appropriate credentialservice agents 150. In one embodiment of the present teaching, thecredential exchange 146 is operable to issue new credentials to OneStopusers, for example, at the demand of OneStop identity center 142. Thecredential exchange 146 may be operable to issue replacement credentialsfor OneStop users or to extend the expiration period of an existingcredential.

In one embodiment of the present teaching, the credential exchange 146is a cloud based service provider that operates independently of OneStopidentity center 142, where secure communication between OneStop and thecredential exchange 146 is maintained.

In the present teaching, end user 110 may include an entity, such as,for example, a person, that communicates with trusted applications 130.The end user may 110 may have access to a number of personal devices,such as, for example, a mobile phone, a personal computer. The end user110 may also have access to a number of security devices, such as, forexample, a smart card, a Symantec token, a RSA secure ID, an Ezio securecard. The end user may also have access to a communicator, such as a laptop computer, a mobile phone, or a tablet computer, which can haveaccess to the Internet and can communicate with service providersonline. The end user 110 may also include biometric collectors, forexample, a voice recorder, a finger print scanner, an iris scanner andany other devices and computer applications that is required to collecta particular biometric sample. The end user 110 may also include anyother credential collector, such as, for example, any device, anycomputer or mobile applications, where by the person may provide inputsabout a particular credential so that the credential can be verified.

FIG. 5 shows a flowchart of an exemplary process in which the OneStopidentity center 142 communicates with a standalone credential exchange146 to manage credentials for OneStop users, according to an embodimentof the present teaching. At step 510, OneStop identity center 142receives an identity request, for example an authentication request ofan end user 110, from a trusted application 130. The authenticationrequest may include the end user's OneStop identifier GUON (First Name,Last Name and & Chosen Name), and an overall LOA level that the trustedapplication 130 requires for the authentication quality.

Assuming, in this example, the end user 110 is a valid, pre-registereduser in OneStop, and the end user 110 has an identity proofing record ofrequired LOA or above. The end user 110 is identified with the user'sGUON and is referenced internally in the OneStop system with acorresponding GUID. At step 520, the OneStop identity center 142 maytranslate the OneStop identifier GUON (First Name, Last Name and &Chosen Name) to the corresponding GUID that uniquely identifies the enduser's 110 account in OneStop.

At step 530, the OneStop identity center 142 may send a credentialrequest to the credential exchange 146. The credential request includes,for example, the GUID of the end user 110, and the LOA that the trustedapplication 110 requires. At step 540, upon receipt of the GUID and thecredential request, the credential exchange 146 look up availablequalifying credentials for the end user 110 based on the GUID and theLOA. For example, the credential exchange 146 may search in thecredential database 148 and obtain a list of all active credentials thatare bound to the GUID and has an LOA at the requested LOA or above.

If the search is not successful and found a qualifying credential forthe end user 110 at step 545, the credential exchange 146 may return afailure response to OneStop identity center 142, at step 546. In oneembodiment of the present teaching, upon receipt of a failure responsefrom the credential exchange 146, the OneStop identity center 142 mayinitiate a process to issue a new credential at the desired LOA to theend user 110 at step 548. In one embodiment of the present teaching,upon successful issuance of the new credential to the end user 110, theOneStop identity center 142 may bind the new credential to the end user110 in the credential exchange 146. For example, the OneStop identitycenter 142 may send a “Bind” request to the credential exchange 146,which may include the new credential information and the GUID whichshall be bound to the new credential.

If the search is successful, the credential exchange 146 provides thefound credentials to the OneStop identity center 142 at step 550. In oneexample, the credential exchange 146 may provide, for each qualifyingcredential, the identifier of the credential (e.g. a serial number of aSymantec token or a serial number of a RSA secure ID). Upon receipt ofthe credential list, the OneStop identity center 142 may display thelist of credentials to the end user 110 in a user interface, such as,for example, the user interface component 220 or 230 as shown in FIG.2-a, FIG. 2-b, respectively.

At step 555, the OneStop identity center 142 may receive a credentialselection made by the end user 110, for example, through a userinterface component 220 or 230 as shown in FIG. 2-a and FIG. 2-brespectively. In one embodiment of the present teaching, user selectionof the credential in the user interface 220 or 230 may trigger thepresentation of a credential verification user interface, where the enduser 110 is enabled to input information needed to verify thecredential. For example, user selection of the Symantec (OneStop) 242-acredential may trigger the presentation of another user interface, suchas, for example, a text box to enter a onetime pass code.

The credential exchange 146 may select a credential service agent 150that provides the verification service of the user selected credentialat step 560. The credential exchange 146 may, for example, initiate averification process in the selected credential service agent 150 atstep 565.

In one embodiment of the present teaching, the OneStop identity center142 collects user inputs that relate to verification of the selectedcredential via a user interface (e.g. the text box to center the onetimepasscode) and pass the user inputs (e.g., the onetime passcode that userprovided) on to the credential exchange 146 in a “CredentialVerification” request. The credential exchange 146 may, for example,assemble information required to verify the credential based on thereceived user inputs to the selected credential service agent 150. Thecredential exchange 146 may also provide to the selected credentialservice agent 150, additional information from the credential databasewith respect to the selected credential, including, for example, theGUID, the verification history of the selected credential, theexpiration period of the selected credential, as well as otherinformation related to the selected credential.

In one example, the end user 110 may have selected a Symantec hardtoken, for example by selecting the Symantec (OneStop) component 252-avia the user interface 230 as shown in FIG. 2-b. In one embodiment ofthe present teaching, the credential exchange 146 may obtain informationneeded to verify the selected credential from the credential record ofthe selected Symantec token and pass them to the Symantec credentialservice agent 150-b. For example, the credential exchange 146 mayprovide the serial number of the Symantec hard token and a onetimepasscode that user provided.

At step 565, the selected credential service agent 150 may verify theselected credential. For example, the selected credential service agent150 may communicate with the end user 110 via a secure channel tocomplete the verification process. For example, the end user 110 mayhave selected a xFA credential, for example by selecting the xFAcomponent 252-b via the user interface 230 as shown in FIG. 2-b. In oneembodiment of the present teaching, the credential exchange 146 mayprovide a link through the OneStop user interface to an xFA clientapplication so that the end user 110 may be enabled to establish asecure channel with the xFA credential service provider.

In this example, the credential exchange 146 may provide an internal xFAID whereby the end user 110 is bound in the xFA system. The internal xFAID may, for example, be stored as a part of the credential record forthe xFA credential of the end user 110 in the credential database 148.The end user 110 may, for example, provide verification informationthrough the secure channel, such as, for example, provide a voicesample, as well as the xFA internal ID, to the xFA credential serviceprovider to complete the verification process of step 565.

As a result of the credential verification step of 565, the selectedcredential service agent 150 may pass the authentication response to theOneStop identity center 142 at step 570. In one embodiment of thepresent teaching, the selected credential service agent 150 may send theverification result to the credential exchange 146.

In another embodiment of the present teaching, the selected credentialservice agent may send the verification result directly to OneStopidentity center 142.

In one embodiment of the present teaching, the selected credentialservice agent 150 includes a credential database and provides credentialbinding services. In this embodiment, the selected credential serviceagent 150 binds the user's OneStop GUID with the user's credentialinformation, such as for example, the user's initial voice sample, theserial number of a hard token. In this embodiment, the OneStop identitycenter 142 may send the credential verification request directly to thecredential service agent 150 with respect to a GUID. The credentialverification agent may receive verification results directly from thecredential service agent 150, at step 570.

In event the credential verification step of 565 fails, the end user 110may, for example be directed to the user interface (e.g., 220 or 230 ofFIG. 2-a, FIG. 2-b) to try again or to select a different credential.

If the credential verification is successful at step 575, the OneStopidentity center 142 may return a positive authentication response to thetrusted application. For example, the OneStop identity center 142 mayprovide an ID token with an expiration time and following the OpenIDConnect protocol. In another example, the OneStop identity center 142may provide a SAML token to confirm the identity assertion. In stillanother example, the OneStop identity center 142 may provide a signeddigital identity for the end user 110.

FIG. 6-a shows a conceptual view of an exemplary role of OneStop inwhich OneStop as an attribute broker among various sites, according toan embodiment of the present teaching. As shown in FIG. 6-a, a person610 may have identities 1 (610-a) to n (610-n) that he has establishedthat are distributed in site 1 to n, respectively. OneStop provides acentralized management for identities 1-n via the trust relationshipbetween the OneStop web site 630 and the various site 1-n.

OneStop provides one universal OneStop identity 620 that may, forexample, access to all attributes provided by identities 1-n. In oneembodiment of the present teaching, OneStop is operable to propagateattribute values across identities 1 to n to provide an efficient mannerin updating shared attributes. For example, Ellen Smith & Willow, asregister with OneStop, may have changed her last name from “Smith” to“Gates” upon marriage. In one embodiment of the present teaching, thelast name attribute is maintained at OneStop; Ellen has, for example,consented to share this OneStop last name attribute with site 1-nautomatically. As a result, OneStop may update sites 1-n with the lastname change in identities 1-n respectively.

FIG. 6-b shows portions of data used in an exemplary attributemanagement feature, according to an embodiment of the present teaching.As a centralized manager for a person's identity, OneStop manages allaccessible identity attributes that are associated with the OneStopuser. In one embodiment of the present teaching, OneStop ensures sourcesite of each attribute and provides guidance as to where else (othersites) such attribute are also used.

In one embodiment of the present teaching, as show in FIG. 6-b, OneStopowns and provides a number of demographic attributes of a person, suchas, for example, first name, last name, date of birth, gender and zipcode. Following the OneStop user's consent (See FIG. 6-d), OneStop mayshare these demographic attributes with a list of applications, such as,for example, sites as listed on the corresponding “Attribute Consumer”column. In the example as shown in FIG. 6-b, OneStop may share theOneStop user's first name, last name and gender with n sites (site 1-n).In contrast, OneStop may share the Date of Birth attribute of the userto only 2 sites (site 1—Citi bank and site n-myhealth.com).

To be a trusted attribute source, OneStop may follow certain protocolsto ensure the accuracies of these attributes. For example, OneStop mayperiodically check with the US post office to ensure that it has themost recent zip code of its use.

FIG. 6-c shows exemplary system diagrams of OneStop where OneStop actsas an attribute broker, according to an embodiment of the presentteaching. The present teaching enables the user to determine the scopeof the attributes that are shared. The present teaching also enables theuser to manage which site the user chooses to be the source ofparticular attribute, and which site(s) may consume (get updates from)the attribute values from the source site. End users 110 in thisembodiment use the OneStop application 635 to interface with the OneStopidentity service 140 for registration and attribute sharing.

The present teaching also enables an attribute exchange among variousapplications with a centralized authorization model. In one embodimentof the present teaching, OneStop applies the OAuth 2.0 protocol toprovide authorization and access control to attribute sharing based onuser consent. In this embodiment, OneStop acts as the pseudo resourceowner. As a result, user authorization can be implemented in onecentralized OneStop authorization server, such as, for example, Oauth2Authorization Server 644. The present teaching alleviates the burden oneach site/resource owner to implement its own authorization server.

OAuth 2.0 protocol has three phases: (1) requesting an AuthorizationGrant; (2) exchanging the Authorization Grant for an Access Token; and(3) accessing the resources using this Access Token. In one embodimentof the present teaching, OneStop uses OpenID Connect(http://openid.net/connect/faq/) as another identity layer on top ofOAuth 2.0 protocol. OAuth applications can get authentication eventinformation over the ID Token and can get the extra claims of theauthenticated user from the OpenID Connect UserInfo endpoint.

Attribute Sharing Manager 640 is operable to manage the attributesharing among various trusted applications 130. As shown in the userinterface below in FIG. 6-d, attribute sharing manager 640 receives userdecisions as to what attributes to share, to which the attributes areshared and store the attribute sharing decisions in an attribute mapdatabase 642.

The attribute sharing manager 640 may also be operable to ensure theaccuracy of the attributes. For example, the attribute sharing manager640 may periodically check with government or authorities to maintainthe accuracies of the attributes. For example, the attribute sharingmanager 640 may periodically check with the address changes requestssubmitted in the US postal to update zip code attribute of OneStopusers. In another example, the attribute sharing manager mayperiodically get updates from the Social Security Administration'swebsite.

In another example, the end user may manually change the attributes. Inanother example, a certified trusted entity may be enabled to conductattribute updates in the attribute sharing manager 640, such as atrusted site of an auditing agency or regulation website, or an identityproof agent.

The attribute sharing manager 640 may keep a record of attributesrevision history, such as, for example, the time, place and manner as tohow the attribute is revised, the value change at each revision.

The OnesStop identity service 140 in this embodiment further includes anOneStop registration service 646 that is responsible for registeringOneStop users upon identity proofing of the users by identity proofingagents 648. The details of OneStop users registration are describedbelow with respect to FIG. 8.

FIG. 6-d shows an exemplary user interface of OneStop where the user maymanage attribute sharing among various trusted applications. The userinterface 650 includes four components: UI component 652, 654, 656, and658 respectively

The UI component 652 allows the user to select one or many attributesthat are to be shared among a set of applications/sites. The UIcomponent 652 also allows the user to update any attribute values, forexample by clicking on the update button. The UI component 652 may alsoallow user to select other attributes that are not currently displayed,by clicking on the “More” button, which may trigger another UI fordisplaying more attributes options.

The UI component 654 allows the user to select the set ofapplication/sites where the attributes selected, for example, in UIcomponent 652, may be shared. The UI component 654 allows the user toconsent to the attributes sharing to the set of selected applications.The UI component 652 may allow the user to select more sites to sharethe selected attributes, for example, by clicking on the “More” button,which may trigger another UI for displaying more application/siteoptions.

The UI component 656 allows user to select a default set of attributeswith new applications. In this example, the user may elect from a listof demographics information, including the user's first name, last name,zip code, gender and birth month and day.

The UI component 658 allows the user to reject any attribute sharingamong the applications, by for example, click on the “Deny” button.

FIG. 7 shows exemplary user interface for an authenticated user of atrusted application to register with the OneStop identity serviceprovider, according to an embodiment of the present teaching. Thetrusted application may be certified to have an overall LOA for itsusers. The trusted application may be a member of the trust frame work,or have been certified by a third party or an government agency to havefollowed the practices to reached LOA when identity proofing for itsusers. In one example, the trusted application is certified at LOA3,thus ensures its users to have passed LOA3 identity proofing. Thetrusted application may also use a LOA3 credential to authenticate itsusers. Assuming OneStop identity service provider is to trust thetrusted application, the authenticated user of the trusted applicationmay be provided an option to become an OneStop user, so that the usermay have access to the OneStop identity services.

In one embodiment of the present teaching, during an active session ofthe authenticated user in the trusted application, the user may haveaccess to the user interface 710, as shown in FIG. 7, to automaticallyregister to OneStop identity service provider. In this example, thetrusted application provided to the authenticated user a list ofattributes that OneStop requires, as shown in UI component 720. The listmay include, for example, the user's 5 attributes as stored in thetrusted application, such as, for example, first name, last name, zipcode, and gender and birth month. The user may elect to consent to thesharing of these 5 attributes. The user may elect to not consent to thesharing of these 5 attributes. The user may also elect to update anyinaccuracy of these 5 attributes. Having user consent to the sharing ofthese 5 attributes, may enable OneStop to initiate a registrationprocess of the authenticated user, which will be explained in moredetail below in FIG. 8.

FIG. 8 shows a flowchart of an exemplary process in which anauthenticated user of a trusted application shares the user's identityattributes in the trusted application with OneStop service provider inorder to register with OneStop and become an OneStop user, according toan embodiment of the present teaching.

In one embodiment of the present teaching, OneStop may enroll users of atrusted application in batch mode. For example, the trusted applicationmay share with OneStop a group of its users' profiles or attributes,such as, for example, demographics attributes. Trusting these users tohave been properly identity proofed by the trusted application at acertain LOA, OneStop may register the group of users in the OneStopsystem in a batch mode. In one example, OneStop may register a group ofusers from an EPCS application, where the EPCS users are doctors who mayprescribe controlled substances to patients. The EPCS users are identityproofed at LOA3 and are authenticated to the EPCS application at LOA3via a two factor authentication process.

OneStop may, for example, check to make sure that the EPCS user does notalready have an OneStop user account. In one embodiment of the presentteaching, OneStop may create a default chosen name for each new userfrom EPCS application and allow the new user to change it when the newuser's first login to the OneStop. For example, OneStop may use the newuser's birth month and day as the user's initial temporary chosen name.For a user who has a birth date of August 16, OneStop may create adefault chosen name, such as, for example, “0816” or “Aug16” or“August16.”

In another embodiment of the present teaching, as illustrated in FIG. 8,an authenticated user of a trusted application may individually registerto the OneStop system. At step 810, the trusted application may obtainthe current authenticated user's consent to share a list of attributeswith OneStop. For example, the trusted application my present to thecurrently authenticated user a user interface, such as for example, userinterface 710 in FIG. 7, a list of attributes that OneStop requires.Upon receiving the current user's consent, the trusted applicationsecurely sends the OneStop the attributes with respect to the currentuser.

At step 820, OneStop receives the current user's identity attributesfrom the trusted application. At step 830, OneStop may, for example,search within OneStop to see if there is any existing user that hasmatching attribute values to the received attributes values. If so, theuser is already registered in OneStop. OneStop may enable the currentuser the option to (a) register a new credential, such as, for example,the credential that the current user used to be authenticated by thetrusted application (via steps 840, 842, 844 and 848); (b) register newattribute(s) of the user with OneStop (step 870).

In one embodiment of the present teaching, in step 840, the current userprovides the current application credential to OneStop. For example, thecurrent user of the EPCS application may provide the serial number ofthe Symantec token to OneStop. In one example, OneStop may also requireuser to provide the onetime passcode showing on the Symantec token. Inone example, OneStop may verify the Symantec token at step 842. Theverification of the selected credential is checked at step 844. Uponsuccessful verification, OneStop may bind the new credential, such as,the Symantec token, to the current user's OneStop account, at step 848.If the verification of the selected credential is unsuccessful, then theprocess exits at step 895.

At step 830, if the current user of the trusted application is not foundwithin OneStop, the user may, for example, provided an option to enrollin OneStop through a user interface at step 832. The user may, forexample, choose to proceed with enrolling in OneStop at 832. If the useropts not to be enrolled in OneStop, the process exits at step 895. Atstep 834, whether the user has passed sufficient identity proofingprocess in the trusted application and has reached sufficient LOA foridentity proofing are checked. If the test is failed at step 834, thenthe process exits at step 895. If the user has passed sufficientidentity proofing process in the trusted application and has reachedsufficient LOA for identity proofing at 834, then OneStop may registerthe user in OneStop at step 850. For example, OneStop may, at step 860,save the current user and the user's attributes in OneStop's identityrepository, such as, for example, the identity database 144.

In one embodiment of the present teaching, OneStop may also provide thecurrent user with the option to register a new credential via steps 840,842, 844 and 848. OneStop may also provide the current the user with theoption to register new attribute(s) from the trusted application withOneStop at step 870.

FIG. 9 shows a flowchart of an exemplary process in which an OneStopuser may register to a new trusted application, according to anembodiment of the present teaching. To register with a new trustedapplication, a user normally needs to provide a significant amount ofinformation with respect the user to the new application. Some of thisinformation, for example, is used for identity proofing purposes. Someof this information is needed for specific use by the new application.The present teaching provides interoperable identities through OneStopwhich allows a trusted new application to delegate the identity proofingtask to OneStop. As a result, the user is relieved of the burden toprovide a lengthy list of information, e.g., fill out a 20 page PDF formonline, and do so repeatedly, as each new application may requiresimilar information for purpose of identity proofing.

In one embodiment of the present teaching, the new application maydecide to trust the identity proofing LOA that OneStop provides andforego the need to acquire these attributes. In another embodiment ofthe present teaching, the new application may still collect a number ofattributes through OneStop attribute sharing mechanism, for example, toperform its own identity proofing process. In this example, the user mayneed to consent to a scope of the attributes that the new applicationmay consume, such as, for example, provide inputs through the userinterface 656 components, as shown in FIG. 6-d.

With respect to user information/attributes required specific to the newapplication, the present teaching provides various novel features.First, OneStop enables attribute sharing, so that the new applicationmay consume existing user attributes from other applications, so thatthe user are also relieved of the burden to provide these attributesrepeatedly. For example, a board certified doctor may have registeredwith an electronic prescription application, such as Rcopia. The doctorhas provided Rcopia with information/attributes relate to his medicaltraining upon registering to the Rcopia application. The same list ofattributes will be needed for a new EPCS application, where the doctormay prescribe controlled substances. With the present teaching, the usermay simply consent the sharing of these attributes from Rcopia to EPCSthrough OneStop.

Additionally, OneStop enables the user to manage these attributes in oneplace, such as, in the Rcopia application. OneStop may enable or toprovide attribute updates from the attribute source/owner, such as theRcopia application, to the attribute consumers, such as the EPCSapplication. As such, the user no longer to do updates to theseattributes, repeatedly, in each application that uses them.

Second, OneStop enables the expansion of the user attributes openlybecause new attributes can be provided to the ecosystem from anyapplication through time. Further, the distributed nature of theattributes which exists in an ever increasing number of applications,will allow a scalable overall ecosystem to expand without limit.

In reference to FIG. 9, a new trusted application may provide an optionfor a new user to register to the new trusted application throughOneStop. Upon user selection of this option, the new trusted applicationmay send to OneStop its registration requirement, including for example,the overall LOA that the new application requires, a list of attributeswith respect to the user that the new application would like to receivefrom OneStop, step 910.

In one embodiment of the present teaching, the new application may alsoprovide a user interface for the user to login to OneStop at the desiredLOA, such as, for example, user interface 220 or 230 as shown in FIG.2-a and FIG. 2-b. If the user successfully logins to OneStop at thedesired LOA at step 920, the OneStop service provider may provide apositive authentication response to the new site at step 950. Otherwise,OneStop responds to the new application with authentication failure atstep 930. At step 940, OneStop my provide options for the failed user toremedy the failed login. In one embodiment of the present teaching, ifthe failure is due to insufficient identity proofing, OneStop mayprovide user interface to enable user to undertake more identityproofing process to reach a desired LOA level. In another example, ifthe failure is due to lacking of a credential of the sufficient LOA,OneStop may initiate a proper credential issuance process.

Upon successful login to the OneStop at the required LOA, the newapplication may, for example, interact with OneStop to complete theregistration process. In one example, the new application requiresadditional attributes from OneStop. The user may, for example, beprovided with a user interface, similar to the user interface shown inFIG. 6-d, so that user may consent to the sharing of the list ofrequired attributes to the new application at step 950.

Further, the new application may enable the user to select a list of newattributes elect to the new application be the source/owner of theseattributes at step 960. The new application may also enable the user toprovide a list of attribute consumer applications/sites for each newattribute, so that these new attributes or their updates can be sharedto the attribute consumer applications/sites, at step 970. In anotherexample, the new application provides new attributes to OneStop andentrust OneStop to be the attribute source for these attributes.

In one embodiment of the present teaching, OneStop may accept the user'screation of these new attribute values in the new application as is. Inanother embodiment of the present teaching, OneStop may provideadditional service, such as, for example, verifying the newly addedattributes and their values before accepting them in the OneStop systemat step 980. For example, a new attribute “NPI number” is entered by theuser of a new eRx application. OneStop may trigger verification servicesfrom another entity, such as, for example, a database that includes themost current NPI number data to ensure the accuracy of the NPI numbervalue. The verification result is checked at step 990. If theverification is not successfully, the process exits at step 995.

Finally, if the verification is successful, OneStop may update theattribute map to include the attribute management settings with respectto the new application, at step 999. For example, OneStop may record theattribute sharing of the existing attributes to the new application.OneStop may also record the new attributes and the consumers of the newattributes. In another example, the new application provides newattributes to OneStop and entrust OneStop to be the attribute source forthese attributes.

FIG. 10 depicts a general mobile device architecture on which thepresent teaching can be implemented. In this example, the user device bywhich end users could use for accessing the trusted applications 130,the OneStop identity service provider 140, and/or the credential serviceagents 150 is a mobile device 1000, including but is not limited to, asmart phone, a tablet, a music player, a handled gaming console, aglobal positioning system (GPS) receiver. The mobile device 1000 in thisexample includes one or more central processing units (CPUs) 1002, oneor more graphic processing units (GPUs) 1004, a display 1006, a memory1008, a communication platform 1010, such as a wireless communicationmodule, storage 1012, and one or more input/output (I/O) devices 1014.Any other suitable component, such as but not limited to a system bus ora controller (not shown), may also be included in the mobile device1000. As shown in FIG. 10, a mobile operating system 1016, e.g., iOS,Android, Windows Phone, etc., and one or more local client applications1018 may be loaded into the memory 1008 from the storage 1012 in orderto be executed by the CPU 1002. The local client applications 1018 mayinclude a browser or any other suitable mobile apps for accessing thetrusted applications 130, the OneStop identity service provider 140,and/or the credential service agents 150 on the mobile device 1000.Execution of the local client applications 1018 may cause the mobiledevice 1000 to perform the processing as described above in the presentteaching. For example, the display of the user interfaces shown in FIGS.2-a. 2-b, 6-d, and 7 may be made by the GPU 1004 in conjunction with thedisplay 1006. User interactions with the user interfaces shown in FIGS.2-a. 2-b, 6-d, and 7 may be achieved via the I/O devices 1014 andprovided to the trusted applications 130, the OneStop identity serviceprovider 140, and/or the credential service agents 150 via thecommunication platform 1010.

To implement the present teaching, computer hardware platforms may beused as the hardware platform(s) for one or more of the elementsdescribed herein. The hardware elements, operating systems, andprogramming languages of such computers are conventional in nature, andit is presumed that those skilled in the art are adequately familiartherewith to adapt those technologies to implement the processingessentially as described herein. A computer with user interface elementsmay be used to implement a personal computer (PC) or other type of workstation or terminal device, although a computer may also act as a serverif appropriately programmed. It is believed that those skilled in theart are familiar with the structure, programming, and general operationof such computer equipment and as a result the drawings should beself-explanatory.

FIG. 11 depicts a general computer architecture on which the presentteaching can be implemented and has a functional block diagramillustration of a computer hardware platform that includes userinterface elements. The computer may be a general-purpose computer or aspecial purpose computer. This computer 1100 can be used to implementany components of the interoperable identity and interoperablecredentials architecture as described herein. Different components ofthe system in the present teaching can all be implemented on one or morecomputers such as computer 1100, via its hardware, software program,firmware, or a combination thereof. Although only one such computer isshown, for convenience, the computer functions relating to the targetmetric identification may be implemented in a distributed fashion on anumber of similar platforms, to distribute the processing load.

The computer 1100, for example, includes COM ports 1150 connected to andfrom a network connected thereto to facilitate data communications. Thecomputer 1100 also includes a central processing unit (CPU) 1120, in theform of one or more processors, for executing program instructions. Theexemplary computer platform includes an internal communication bus 1110,program storage and data storage of different forms, e.g., disk 1170,read only memory (ROM) 1130, or random access memory (RAM) 1140, forvarious data files to be processed and/or communicated by the computer,as well as possibly program instructions to be executed by the CPU 1120.The computer 1100 also includes an I/O component 1160, supportinginput/output flows between the computer and other components thereinsuch as user interface elements 1180. The computer 1100 may also receiveprogramming and data via network communications.

Hence, aspects of the method of interoperable identity and interoperablecredentials, as outlined above, may be embodied in programming. Programaspects of the technology may be thought of as “products” or “articlesof manufacture” typically in the form of executable code and/orassociated data that is carried on or embodied in a type of machinereadable medium. Tangible non-transitory “storage” type media includeany or all of the memory or other storage for the computers, processorsor the like, or associated modules thereof, such as varioussemiconductor memories, tape drives, disk drives and the like, which mayprovide storage at any time for the software programming.

All or portions of the software may at times be communicated through anetwork such as the Internet or various other telecommunicationnetworks. Such communications, for example, may enable loading of thesoftware from one computer or processor into another, for example, froma management server or host computer of the search engine operator orother explanation generation service provider into the hardwareplatform(s) of a computing environment or other system implementing acomputing environment or similar functionalities in connection withgenerating explanations based on user inquiries. Thus, another type ofmedia that may bear the software elements includes optical, electricaland electromagnetic waves, such as used across physical interfacesbetween local devices, through wired and optical landline networks andover various air-links. The physical elements that carry such waves,such as wired or wireless links, optical links or the like, also may beconsidered as media bearing the software. As used herein, unlessrestricted to tangible “storage” media, terms such as computer ormachine “readable medium” refer to any medium that participates inproviding instructions to a processor for execution.

Hence, a machine readable medium may take many forms, including but notlimited to, a tangible storage medium, a carrier wave medium or physicaltransmission medium. Non-volatile storage media include, for example,optical or magnetic disks, such as any of the storage devices in anycomputer(s) or the like, which may be used to implement the system orany of its components as shown in the drawings. Volatile storage mediainclude dynamic memory, such as a main memory of such a computerplatform. Tangible transmission media include coaxial cables; copperwire and fiber optics, including the wires that form a bus within acomputer system. Carrier-wave transmission media can take the form ofelectric or electromagnetic signals, or acoustic or light waves such asthose generated during radio frequency (RF) and infrared (IR) datacommunications. Common forms of computer-readable media thereforeinclude for example: a floppy disk, a flexible disk, hard disk, magnetictape, any other magnetic medium, a CD-ROM, DVD or DVD-ROM, any otheroptical medium, punch cards paper tape, any other physical storagemedium with patterns of holes, a RAM, a PROM and EPROM, a FLASH-EPROM,any other memory chip or cartridge, a carrier wave transporting data orinstructions, cables or links transporting such a carrier wave, or anyother medium from which a computer can read programming code and/ordata. Many of these forms of computer readable media may be involved incarrying one or more sequences of one or more instructions to aprocessor for execution.

Those skilled in the art will recognize that the present teachings areamenable to a variety of modifications and/or enhancements. For example,although the implementation of various components described above may beembodied in a hardware device, it can also be implemented as a softwareonly solution—e.g., an installation on an existing server. In addition,the dynamic relation/event detector and its components as disclosedherein can be implemented as a firmware, firmware/software combination,firmware/hardware combination, or a hardware/firmware/softwarecombination.

While the foregoing has described what are considered to be the bestmode and/or other examples, it is understood that various modificationsmay be made therein and that the subject matter disclosed herein may beimplemented in various forms and examples, and that the teachings may beapplied in numerous applications, only some of which have been describedherein. It is intended by the following claims to claim any and allapplications, modifications and variations that fall within the truescope of the present teachings.

We claim:
 1. A method implemented on a computing device having at leastone processor, storage, and a communication platform capable of making aconnection to a network for managing identity information of a person,the method comprising the steps of: receiving the person's name afterthe identity of the person has been proved at an identity proofing (IDP)level of assurance (LOA); receiving information related to a credentialthat is associated with the person, wherein the credential can beverified by a credential verification service at a LOA that is of thesame or lower level than the IDP LOA; obtaining a chosen name of theperson, wherein a combination of the person's name and the chosen nameuniquely identifies the person; creating a digital identity based, atleast in part, on the person's name and the chosen name; generating aglobally unique identifier (GUID) that associates with the digitalidentity and binds to the person; binding the GUID with the credential;storing a record of the person that includes at least the IDP LOA andinformation related to the credential and the credential verificationservice; and transmitting information to the credential verificationservice that the person is to be authenticated based on a real-time userinput associated with the credential.
 2. The method of claim 1, whereinbinding the GUID with the credential occurs at an identity center or ata credential exchange.
 3. The method of claim 2, wherein the identity ofthe person is unknown to the credential exchange.
 4. The method of claim1, wherein the identity of the person has been proved by an IDP source.5. The method of claim 4, wherein the IDP source includes at least oneof: an identity proofing service provider that is an approved member ofa trust framework; a government agency; a trusted healthcareorganization; and a trusted application wherein users of the trustedapplication passed the identity proofing at the IDP LOA.
 6. A methodimplemented on a computing device having at least one processor,storage, and a communication platform capable of making a connection toa network for authenticating an online user, the method comprising thesteps of: receiving an authentication request originated from the onlineuser in connection with an application having a first level of assurance(LOA), wherein the authentication request includes the online user'sinput; searching a digital identity based on the online user's input;obtaining a globally unique identifier (GUID) associated with thedigital identity when the digital identity is found; providing one ormore credentials that are bound to the GUID at the first LOA or a higherLOA; receiving a selection of at least one credential from the one ormore credentials; retrieving information of the selected at least onecredential that includes a credential verification service capable ofverifying the selected at least one credential; requesting verificationof the selected at least one credential of the online user based on theGUID; receiving a verification response; and authenticating the onlineuser at the first LOA when the verification response indicates that theselected at least one credential is successfully verified.
 7. The methodof claim 6, further comprising denying authentication of the online userwhen the digital identity is not found.
 8. The method of claim 6,wherein the step of requesting verification of the selected at least onecredential of the online user based on the GUID comprises: solicitinginformation associated with the selected at least one credential fromthe online user; and sending a verification request to the credentialverification service with the GUID and the received informationassociated with the selected at least one credential.
 9. The method ofclaim 6, wherein the step of requesting verification of the selected atleast one credential of the online user based on the GUID includessending a verification request to the credential verification servicewith the GUID.
 10. The method of claim 6, wherein the first LOA is 2 or3.
 11. The method of claim 6 further comprising the steps of: providing,upon the successful authentication, the one or more credentials;receiving a choice of at least one of the one or more credentials; anddisabling the chosen at least one credential.
 12. The method of claim 6further comprising the steps of: receiving, upon the successfulauthentication, information about a credential with an associated LOAthat is the same or lower than the first LOA, as well as a credentialverification service capable of verifying the credential; and bindingthe GUID with the credential and the associated LOA.
 13. The method ofclaim 12 further comprising the step of: storing the receivedinformation; or sending the received information to a credentialexchange.
 14. The method of claim 6, wherein an authenticated session iscreated upon the successful authentication of the online user.
 15. Themethod of claim 14, further comprising sharing the authenticated sessionwith another application.
 16. The method of claim 14, wherein theauthenticated session expires at a predetermined period of time.
 17. Themethod of claim 16, wherein the predetermined period of time isconfigurable.
 18. A method implemented on a computing device having atleast one processor, storage, and a communication platform capable ofmaking a connection to a network for authenticating an online user, themethod comprising the steps of: storing one or more credentialsassociated with a globally unique identifier (GUID) corresponding to aperson; receiving the GUID and a first level of assurance (LOA)associated with an application; determining at least one of the one ormore credentials, wherein each of the determined at least one credentialis at the first LOA or a higher LOA; and providing the determined atleast one credential so that the online user who claims to be the personcan be authenticated based on a credential selected from the at leastone credential.
 19. The method of claim 18 further comprising receivinginformation about one of the one or more credentials associated with theGUID at a LOA from an identify center.
 20. The method of claim 19,wherein the information further includes a credential verificationservice capable of verifying the credential.